 |
Choosing the right
multiprocessor development tools While multicore system-on-chip (SoC) devices may be relatively new in the
desktop market, the embedded world has been using them for the past decade.
There are several advantages to using a multicore device in an embedded
application. One reason is power efficiency.
Take the example of mobile handsets, where battery life is an important
requirement. Many of these systems are based on dual-core heterogeneous chips
containing a microprocessor and a digital signal processor. These heterogeneous
multicore devices offer better performance per watt as compared to a DSP or MCU
alone. System designers will partition tasks to the DSP and the MCU, letting
each processor perform the tasks for which it has been optimally designed.
Programmable multicore system-on-chip (SoC) processors are common in many
applications, from wireless handsets to desktop computers and automotive
controllers. While there are clear benefits to multicore SoCs in terms of cost,
performance and power consumption, the burden is on the embedded software
developer to manage the additional complexity of programming and debugging
multiple processors. Depending on the system architecture, issues include taking
advantage of parallelism, managing interprocessor communication, using embedded
operating systems, and coordinating the behavior of multiple processors during a
debug session.
Another class of multicore programmable devices contain “intelligent”
programmable on-chip peripherals, such as DMA controllers or IO processors, in
addition to a microprocessor. The on-chip peripherals have their own instruction
set and are C programmable. Finally, there are homogeneous multicore devices,
with multiple identical cores on a single chip. A telecom basestation processing
thousands of data channels may use hundreds of multicore DSPs. Putting multiple
cores on a single chip helps reduce board space and increase density.
From a software development perspective, a multicore system is one in which
there is more than one core for which software needs to be written, whether
these cores are found all on one chip, as in the examples above, or spread
across multiple chips or boards. What are the things to be aware of when
choosing development tools for a multiprocessor system?
For multicore programming and debugging, the tools requirements will depend
on the level of interaction between the multiple cores, and the hardware support
that the chips provide for multicore programming and debugging. We’ve identified
five levels of multicore tools requirements which can serve as a guide to
determining tools needs for a given project. The requirements are cumulative as
the levels increase. If you are at level 1, only the requirements at that level
apply. If you are at level 4, you should consider all the requirements from
levels 1 through 4.
Level 1: applications programming on a multiprocessor OS
Level 2: Board bring-up, multiple cores, independent of one
another
Level 3: Board bring-up, multiple cores with loose coupling
Another useful debugger technique will be the ability to specify multicore
debug control. If you are debugging interprocessor interaction and detect an
error on one core, it can be useful to stop multiple cores simultaneously. Does
the debugger provide the user a way to start, stop and step more than one
processor simultaneously? If a core halts due to an illegal instruction, can the
debugger stop other cores as well?
Level 4: multicore device with on-chip multicore debug logic
Level 5: device with multicore trace support
Developers embarking on multicore software development need to deal with the
additional complexity that multicore brings in order to harness the advantages.
Having robust debugging tools which support the particularities of multicore can
go a long way to help.
One size does not fit all. A developer’s particular requirements depend on
what stages of software development they program to, and what level of multicore
support their system implies.
Joseph Dubin is a product manager in the Developer Technology Organization
at Freescale Semiconductor, Inc.
Copyright 2005 © CMP Media LLC
By Joseph Dubin, Embedded.com
>:B 31 2005 (10:46 AM)
URL: http://www.embedded.com/showArticle.jhtml?articleID=172900847
At level
1, the embedded software engineer is writing applications on a pre-existing
multitasking/multithreading embedded OS, and the OS is handling interprocessor
communication and scheduling. Tools here should provide OS awareness, and
support the OS’s multithreading model. Since we assume that the OS handles the
underlying hardware, and the OS is stable, the tools do not need to provide
access to multicore hardware features. Commercially available multicore
operating systems are available from several companies including Enea, QNX and
Wind River Systems.
A level two system has multiple programmable processors in
separate chips, with no interprocessor communication or dependency – each
processor functions independently from the others. The processor chips may be on
separate hardware debug scan chains, or may share a single scan chain. If a
developer does not need to program more than one processor at a time, there are
no particular multicore debug requirements for a level 2 system. If the same
developer will be writing code for more than one of the cores, then it may be
useful to have a tool set which can program and debug multiple cores inside a
single IDE session. How does the tool set manage debugging more than one
processor at a time? Does the project manager have the ability to load code for
multiple CPUs?
Level
three adds loose coupling between multiple chips, where there is interprocessor
communication, typically by message passing or shared memory. The architecture
may be homogeneous or heterogeneous, and devices may share a debug scan chain.
Since there is a level of synchronization, the devices may have a specific
initialization sequence that a debugger needs to follow. Considerations here
include: does the IDE handle more than one core in a single session, or do you
need to run multiple IDEs, one for each core? How does the IDE manage screen
real estate when working with multiple cores? Does the IDE have a multicore
project manager which can load files for each core, and specify any particular
initialization sequence? How do you customize the JTAG scan chain to reflect the
devices to debug?
Here,
one or more of the devices have on-chip multicore debug features. Many multicore
devices have debug registers which can trigger behaviors like stopping core B
when core A halts due to a breakpoint or illegal instruction. This makes the two
cores halt almost simultaneously, with a much smaller skid as compared to a
debugger on the host detecting that core A halts, and then sending a halt
command to core B. Do the debug tools provide a simple way to access hardware
multicore debug features?
Level five is for
multicore devices with hardware support for multicore trace. The key thing to
look for here: do the debug tools support multicore trace?
